The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:
3GPP third generation partnership project
ACK acknowledgement message
CRC cyclic redundancy check
DL downlink
eNodeB node B/base station in an E-UTRAN system
E-UTRAN evolved UTRAN (LTE)
HARQ hybrid automatic repeat request
HSPA high speed packet access
LTE 3GPP long term evolution
LTE-A long term evolution-advanced
NACK non or negative acknowledgement message
UE user equipment
UL uplink
UTRAN universal terrestrial radio access network
One well-established technique for improving reliability in wireless communications is use of the ACK/NACK procedure whereby the receiver of a wireless message/data replies to the sender with confirmation (ACK) or not (NACK) whether the data was properly received. These serve to inform the original sender whether or not it needs to re-transmit the original message (or portion thereof). To limit the control signaling overhead these ACK and NACK messages occupy various adaptations of this basic automatic-repeat-request protocol have arisen and so the general process in many wireless systems such as HSPA, LTE and LTE-A is now termed HARQ.
FIG. 1 illustrates the general principle. Assume the sender is a network access node that sends a packet (packet A) to a receiver which is a UE, but the same process operates for packets sent uplink or even device-to-device communications which are generally neither uplink nor downlink. The sender stores packet A in its HARQ memory at 101 and sends it at 102. The receiver assesses whether packet A is properly received, such as by checking a CRC bit or bits included within the message itself. If the CRC check passes the receiver sends an ACK to the sender. If it fails as at 103 or if the receiver never receives a packet at a scheduled time the receiver at 104 sends a NACK to the sender. The ACK and NACK may take various forms: explicit bits on a HARQ indicator channel; on-time UL data from the UE may be considered an ACK for the most-recently sent DL data; lack of an on-time ACK may be interpreted at a NACK. These and various other arrangements are published in various wireless protocols so that both network and UE understand a common meaning for whether data was or was not correctly received.
HARQ implies that the sender at step 101, and sometimes also the receiver at step 103, of the data (packet A) must retain the packet until the relevant ACK is communicated. In the FIG. 1 example the sender needs to retain the packet for possible re-transmission, and for the case of a NACK the receiver may also retain the initially received (corrupted) packet A at 103 to aid in properly decoding the re-transmission of that same packet which the receiver expects to receive next. In what is termed as chase re-transmission, the re-transmitted packet is an exact copy of what was originally sent and NACK'd; whereas in incremental redundancy shown at FIG. 1 the re-transmission following the NACK at 104 uses a simple form of coding so different parts of the original packet are sent in different re-transmissions. FIG. 1 shows this as the sender creating at 105 packet A′ from the original packet A (which was retrieved from the sender's HARQ memory) which is then sent at 106 in response to the NACK. In some incremental redundancy schemes these different versions on the packet can be uniquely decodable so that any version of the packet can be used to decode the whole packet; while other schemes utilize non-decodable re-transmissions meaning that UE needs the preceding versions of the packet in question to combine and decode with the incremental versions. FIG. 1 shows at 107 that the receiver retrieves packet A from its HARQ memory for use in decoding packet A′. But even with chase re-transmission the receiver might find it useful to retain the original packet for use in joint decoding with the re-transmitted packet. Regardless of which re-transmission scheme is in use, the corrupted version of the original packet is stored in the receiving party's local memory as shown at 103. This version is termed in the wireless arts as quantized soft bits, since they are retained at step 103 for possible combination with later (re-transmitted) versions of the data at step 107.
One issue that arises with HARQ protocol is the large memory requirements involved in order to fully utilize the improved reliability HARQ provides. Since memory and processing power are typically more limited in the UE than in the network access node the following will assume the UE is the data recipient, but these teachings are equally valid for both UE and network nodes. The trend in wireless communications has been for some time an increased data rate (as well as the size of the individual packets) and also an increase in the number of parallel HARQ processes (i.e. number of different separate packets that undergo re-transmission process at the same time). This has a significant impact on the total amount of memory which needs to be allocated for HARQ. Conventionally in HSPA and LTE the quantization level of the soft bits has typically been in the order of 5, or more, bits per soft bit.
Related to the memory capacity requirements are power requirements, since each memory access consumes power which at the UE comes from a finite portable source. When the memory to access for a given set of soft bits becomes too large there is a potential latency issue which might impact the UE's real-time processing of the packet re-combinations. The latter is particularly relevant for streaming video and similar data which exhibits both high data rate and tight timing requirements.
Past techniques and proposals to address the above HARQ memory issues have included not storing the earlier transmissions at all, which can retain the added reliability which HARQ offers only where the incremental redundant re-transmissions are uniquely decodable packets. Another technique that can be used e.g. in LTE time-division duplexing implementations with a large number of parallel HARQ processes is to reserve some memory for HARQ but an amount insufficient for worst-case performance. But in a highly loaded scenario this means the original packet from some HARQ processes is never stored and if that packet happens to generate a NACK the re-transmission procedure might not resolve the corrupted data. Still a third technique is to apply fewer bits to represent the soft bits when storing in the HARQ memory. This can be seen as a compromise between complexity and performance.